iT邦幫忙

2026 iThome 鐵人賽

DAY 27
0
自我挑戰組

React 入門到實作與除錯|30 天哩ㄟ刻系列 第 27 篇

Day 27 : 蹭熱度,做個需求顧問 AI 網站

  • 分享至 

  • xImage
  •  

什麼都要提到 AI,那就來蹭一下?

現在好像什麼都要加上 AI,這次的小專案也來蹭一下。剛好開始做專案的時候,我們經常只有一個模糊的想法或概念,還沒想清楚需求,就急著動手。

接下來三天,來做一個「 需求顧問 AI 網站 」,主要的任務是就開發前的需求釐清:透過填表與追問,把想法整理成可討論的需求 ( 對啦,就是 grill-me )

問題來源

就上面說的,模糊的需求是經常碰到的問題,例如「我想做一個工具,讓店裡交班不要漏事情」,但提案方也不知道具體的細節想要什麼,所以我們做一個可以分析需求的網站,讓想法可以變成拿去討論的需求。

拆解情境

對於這個需求顧問來說,需要拆解使用者的想法,我們可以透過填表、問題對話引導,產生需求討論稿,讓一個模糊的想法更明確。

先稍微列出幾個情境:

情境 可能的原因 對應的設計
不知道如何開始填表 只有模糊想法,不熟悉需求整理的用語 少量欄位搭配簡單提示,允許背景暫時留白
填完表單,資訊仍不完整 固定題目難以涵蓋不同專案的情境 根據已填內容與資訊缺口,安排後續追問
訪談一直延伸,不知道何時結束 缺少進度與階段成果 顯示輪次,缺少的列為待確認
有很多回答,卻難以討論需求 問答尚未連結到功能理由與完成標準 整理成附依據、理由、故事與驗收條件的候選項目
無法判斷內容是原話還是 AI 推測 資訊來源與確認狀態沒有區分 保留使用者說法,標示推測與未知

這樣看下來,網站最少需要串起三件事:讓使用者容易開始、依照回答補足資訊、協助將內容整理成有依據的需求項目。

方案選擇

上面的情境拆解讓我們有了初步的目標,現在我們要更進一步的知道有哪些方案可以完成,以及這個需求顧問要怎麼樣才算完成

首先我們需要知道幾個常見的需求拆解做法:

  • 探索資訊:5W1H、5 Whys。
    • 5W1H 用人事時地物、原因、方法,提取需求的背景資訊。
    • 5 Whys 沿著回答深入探索原因。

5W1H 說明
5 Whys 說明

  • 整理需求:需求清單、User Story、Use Case。
    • 需求清單將內容整理成獨立項目並保留來源。
    • User Story 說明誰想做什麼、為了什麼價值。
    • Use Case 則展開角色、操作流程與例外情況。

需求清單與 Use Case 說明
User Story 說明

  • 確認結果:AC 驗收條件。 將完成標準寫成可觀察的結果,例如用 Given–When–Then 描述前提、操作與預期結果,方便討論與檢查。

Given–When–Then 說明

這些方法提供提問與整理的依據,我們來比較可以承接這些工作的互動方案:

方案 提供 額外問題
固定表單 蒐集一致的背景資訊 題目難隨回答深入
自由 AI 聊天 彈性討論不同想法 使用者要自己帶領方向與整理結果
簡短表單加引導式訪談 建立背景資訊,再逐步追問 要控制輪數、區分推測並整理需求

上面的需求拆解方法可以做成填表或引導式問答畫面,讓使用者通過輸入來達到需求整理。

這裡我們選擇混合的方案,用表單提供起點,網站說明目前進度,AI 根據既有內容找出下一個值得補足的資訊,最後整理出可討論的需求。

需求設計

根據上面的方案選擇,有這幾個需求發生:

  • 需求探索方法放進互動流程。
    • 表單式問卷:先建立背景。
    • 對話問答:依照回答補足資訊。
  • AI 串接。 讓模型參考表單與前文,產生追問與討論稿。
  • 結果驗證與輸出。 整理成需求項目,讓使用者核對並帶走。

具體細節就可以來列一下:

  • 表單以 5W1H 設計提問與提示。
  • 追問借用 5 Whys 探索原因的方式。
  • 輸出與核對採用 需求清單+User Story+AC。

這個組合就能大致交代背景、功能理由與完成標準了~~(畢竟時間也不多)~~。

整理成表格,方便我們後面對照著做:

功能 原因 完成條件
用表單建立背景 使用者需要容易開始的入口 問題空白時提示填寫,只填三欄必填後開始
依表單與前文逐題追問 不同專案有不同資訊缺口 一次一題,與前文相關,避免重問已回答的內容
第三輪後整理成果 訪談需要明確的階段終點 第三題回答成功後顯示討論稿
整理成簡短需求項目 回答需要轉成能討論的功能與理由 三項候選需求,每項附理由、使用者故事與驗收條件
複製討論稿 成果需要能帶進後續需求討論 可以複製結果,並顯示成功或失敗提示

首先是表單主要會放「想解決的問題、誰會用、目前如何處理」三欄必填,其他資訊會透過訪談補足。並且以 5W1H 作為資訊檢查的依據。

為了避免回答的壓力,設計上一次只會追問一題,最多三輪。我們借用 5 Whys 概念沿著回答深入探索,不會強制問滿五次,沒有釐清的原因與限制,就留到待確認事項。

接著要把每項需求的理由連結相關回答,讓使用者能回看依據。AI 產生的 User Story 與驗收條件都只是討論材料,資訊不足時就會標示待確認。

系統架構

OK,前面的需求可以分成三個部分:React 網站、輕量 API、AI 模型服務。

  • React 網站負責互動

    • 顯示表單、問答紀錄、輪次與討論稿。
    • 提供複製與重新開始。
    • 表單與問答保留在前端,每次請求一起送出,讓後續追問能參考前文。
    • 等待時停用提交與重設,失敗保留輸入並提供重試,讓填答可以接續。
  • 輕量 API 負責 AI 串接與流程控制

    • 統一管理提問與整理指令。
    • 檢查輸入、判斷目前輪次,再決定要請模型追問或整理。
    • 三輪限制。
    • 回應檢查結果欄位是否可用,再交給前端顯示。
  • AI 模型服務負責產生內容

    • 根據表單與回答,以 5W1H 檢查資訊缺口。
    • 沿著回答探索原因,整理出問題摘要、需求清單與待確認事項。
    • 需求項目附上理由、User Story 與建議 AC
    • 固定回傳欄位,讓網站可以穩定顯示與複製。

三個的關聯會是:

https://ithelp.ithome.com.tw/upload/images/20261011/20184332iN63TpH7Sd.png


基本上這就是我們要做的小專案該有的內容,明天就來大趕工吧。/images/emoticon/emoticon69.gif

參考資料


上一篇
Day 26 : 記住你了,MUI 收藏城市與保存設定
下一篇
Day 28 : 蹭熱度,做個需求顧問 AI 網站之二
系列文
React 入門到實作與除錯|30 天哩ㄟ刻 共 29 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言